500 MB Nyheder Direkte fra Internet 2/500 MB nyheder direkte fra internet CD 2.iso/start/data/text/faq-0585.txt

Text File | 1995-05-03 | 28KB | 655 lines

Archive-name: games/design-FAQ
Last Updated: Feb. 21, 1994
Version:      1.54

First, a note:

Sorry about this posting being late.  Unfortunately, I accidentally
deleted most of my home directory on the Unix system I use, and had
to wait for my directory to be restored from tape.  In addition,
because of the delay, I haven't had a chance to do any updating to
the FAQ this time.

--Travis

--------------------------------------------------------------------


REC.GAMES.DESIGN list of Frequently Asked Questions (FAQs).

This list is posted monthly to rec.games.design, rec.answers, and
news.answers.

The list is maintained by Travis Casey.  Any ideas for changes,
additions, or corrections are exceedingly welcome, and should be
directed to:

     [e-mail]

Please put "rgd FAQ" or something similar in your subject line, as
this is not the only FAQ I maintain.

---------------------------------------------------------------------

TABLE OF CONTENTS  (New or changed items are marked with an * ).
-----------------

Section 1 -- General Questions

     1.  What is the purpose of this group?
     2.  I'm writing a computer game in the BOGUS language, and I
     need help!
     3.  Is this group just for RPG's?
     4.  What is proper etiquette for this group?
     5.  Are there any books on game design available?
  *  6.  Where can I find info about games on the net?
     7.  What is the address of company X?
     8.  I'm worried about protecting my ideas.  How do I copyright
     my game?
     9.  Do you have any advice for a beginning game designer?

Section 2 -- RPG Questions

     1.  What is net.rpg's status?
     2.  What is net.rpg, for that matter?
     3.  What is FUDGE?
     4.  I'm trying to design an RPG.  What advice do you have?

Section 3 -- Computer Games

     1.  What is FRUA?
     2.  What's the best language to write a game in?

Section 4 -- Wargames and Boardgames

     1.  I'd like to get a wargame published.  What should I do?
  *  2.  FTP-able games.

---------------------------------------------------------------------

Section 1 -- General Questions

1.  What is the purpose of this group?

     This group is meant for discussion of the design aspects of
     games--board games, computer games, role-playing games (RPG's),
     card games, or any other sort of game.  This is the place to
     post ideas for games, thoughts about systems, questions about
     how something should work in a game, or anything else about
     designing games.

2.  I'm writing a computer game in the BOGUS language, and I need
    help!

     This isn't a good place to look for help with computer
     languages.  The main focus of this group is on *design*, not
     *implementation*.  Try the *.lang.* and *.programmer groups
     first, especially rec.games.programmer.

3.  Is this group just for RPG's?

     No.  As mentioned above, all sorts of games can be discussed
     here.

4.  What is proper etiquette for this group?

     It's basically the same as for any other group:  use informative
     subject lines, if you're posting about a specific thing, include
     what it is in the Subject: field (e.g. "FUDGE:" at the start of
     a Subject line for an article discussing the FUDGE game; see
     below)

     Don't get mad if someone doesn't like your pet idea:  listen to
     them and try to answer their points.  Remember, the purpose of
     this group is for us to discuss our ideas and improve upon them.

     Some of the things that shouldn't go here include announcements
     that you've made a new game (unless you're posting it up for
     review), questions about what a specific rule in a specific game
     is supposed to mean, announcements of things that don't relate
     to designing games (e.g., role-playing BBS's, FTP sites for
     games, etc.), and anything else that doesn't relate to game
     DESIGN.

5.  Are there any books on game design available?

     Some books that may be of assistance are:

     Crawford, Christopher; _The Art of Computer Game Design_
      Osborne/McGraw-Hill.  No longer in print, but available
      by writing the author c/o Osborne/McGraw-Hill.

     Dunnigan, James; _The Complete Wargame Handbook_
      William Morrow and Co., ISBN 0-688-10368-5

     Dupuy, T. N.; _Numbers, Predictions, and War_
      Hero Books, ISBN 0-915979-06-3

     Levy, David.  _Computer Gamesmanship_
          Simon & Schuster.  ISBN  0-67149-532-1
          Focuses on chess, checkers, and poker algorithms.

     Peek, Stephen; _Game Plan: The Game Inventor's Handbook_
      Betterway Publications, ISBN 1-55870-315-2

     Perla, Peter; _The Art of Wargaming_
      Nav. Inst. Press, ISBN 0-87021-050-5

     Prados, John; _Pentagon Games_

     Schuessler, Nick and Steve Jackson; _Game Design:  Volume One:
      Theory and Practice_.  Steve Jackson Games.  No longer
      in print, no further volumes were produced.

     Schmittberger, R. Wayne; _New Rules for Classic Games_

     Strategy & Tactics Magazine; _Wargame Design_
      SPI, ISBN 0-917852-01-X

     Zocchi, Lou;  _How to Sell Your Game Design_
      Gamescience (GS 10404)

     Note that these references have been garnered from the net, and
     I make no guarantee as to their accuracy.

6.  Where can I find info about games on the net?

     The best site that I currently know of is the Games Domain
     site on the Web.  There, you can find FAQ's for plenty of
     games, links to WWW sites for specific games, including ones
     run by the companies that put out the games, FTP links for
     games, a link to a list of RPG companies, and much, much
     more.  The address is:

       http://wcl-rs.bham.ac.uk/GamesDomain

7.  What is the address of Company X?

     Two lists of game company addresses are kept on Usenet, as far
     as I know; here's the info:

     The "Wargame Company E-mail Addresses" list is kept by
     [e-mail].  It is generally posted once a month to
     rec.games.board and rec.games.design.

     Johnathan Sari ([e-mail]> maintains a
     "Complete Role-Playing Game Companies List," with the snail mail,
     email, and fax/phone numbers of most RPG companies.  This list
     is periodically posted to rec.games.frp.misc.

8.   I'm worried about protecting my ideas.  How do I copyright
     my game?

     Well, I've got good news for you, and bad news.  First the
     good:

     If you're in the US, England, any Western European Country,
     Canada, or Australia, anything you write is automatically
     considered to by copyrighted under the terms of the Berne
     convention that all these countries adhere to.

     Now, the bad news:  a copyright does NOT protect your ideas.
     All a copyright does is protect the _expression_ of an idea.
     Thus, it's perfectly legal for someone to take all the rules
     of, say, Advanced Dungeons & Dragons, paraphrase them, and
     eliminate references to Dungeon Master and a few other terms
     TSR has trademarked, and sell the resulting product.

     That said, including a copyright notice in your work does
     give you one benefit:  it makes it easier to collect damages
     if someone does copy your material.  If there is no copyright
     notice, the copier can claim "innocent infringement" (that
     is, "I didn't know I couldn't copy it") and get off with a
     slap on the wrist.  In addition, you may want to look into
     registering your copyright.  In the US, at least, this
     provides definite proof that you wrote your material first,
     and allows you to collect money from copiers beyond simple
     damages.

     To protect the ideas of a game, a patent would be necessary.
     In general, though, it's probably not worth the effort.  To
     qualify for a patent, a game must include physical components
     beyond simple board, dice, and rules, so that it can qualify
     as a "machine."  Thus, most games won't be eligible.  In
     addition, obtaining a patent is a long and complicated process
     which will almost certainly require you to hire a patent
     attorney, pay his/her large fees, and pay a large (and
     nonrefundable!) amount of money for a patent application.

     In my opinion, though, you needn't worry about protecting
     your ideas.  Chances are that if you've thought of it,
     someone else has as well.  Thus, refusing to discuss aspects
     of your game in order to protect your ideas isn't likely to
     keep anyone else from using that idea, and will prevent you
     from getting feedback which might help you improve the idea.

     (A bit from my own experience:  a few years ago, I came up
     with an idea for a die-rolling method for an RPG which I had
     never seen before and which greatly simplified the system I
     was making.  Since then, I've encountered at least three
     systems which also use the same method, none of whose authors
     could possibly have seen my work.)

     In general, games do not succeed because of any single "neat
     idea;" in fact, innovative games are less likely to succeed
     because most people do not want to learn large amounts of
     unfamiliar material.

9.   Do you have any advice for a beginning game designer?

     Sure.  Here's my version of the 10 commandments:

     1.  WRITE GAMES YOU LIKE.

     Never put something in a game or take something out just
     on someone else's say-so.  If you and your friends like
     it, chances are somebody else will too.

     In the same vein, don't write a game on subject X just
     because it's the current "hot topic."  Write games on
     the things YOU like and hopefully your enthusiasm will
     come through.

     2.  EXPERIENCE IS THE BEST TEACHER.

     The best way to learn game design is to read a lot of
     games, play a lot of games, analyze those games, and
     design your own games or game extensions.  Since my
     main experience is with RPG's, my examples will come
     from them, but the idea is applicable to all kinds of
     games.

     I've read tons of RPG's:  somewhere over 50 last time
     I bothered to count.  I've played most of these, and
     GM'ed over 30.  In addition to playing and gamemastering,
     though, I also analyze games.  What makes this game good?
     What's bad about it?  How would I modify it to make it
     do this instead?  What areas does it represent well?
     What areas does it represent poorly?  Why?

     Having played and analyzed other games, I use this
     knowledge to help with my own games.  For example, both
     Champions and DC Heroes had good results using an
     exponential attribute scale for superhero gaming.  Thus,
     if I were going to design a superhero game, I would know
     that an exponential scale can work very well.  This kind
     of analysis gives you a bank of "proven" concepts to
     work with.

     3.  TEST, TEST, AND TEST SOME MORE.

     Playtest your games.  Play them as much as possible;
     get other people to play them, preferably without you
     around, and talk to them afterwards.  (Having other
     people play the game without your presence is called
     blind-testing, BTW.)

     In addition, think about your rules.  Consider
     hypothetical situations and work out the probabilities
     involved.  For example, if you're making an RPG, try
     figuring out the percent chance an average person has
     of hitting a man-sized target with a bow at a range of
     1 meter, 5 meters, 10 meters, 50 meters, and 100 meters.
     For a WWII game, examine your CRT and figure out the
     probability that a small infantry unit will damage a tank
     unit.  Repeat the calculations under different conditions;
     different terrain, at night, etc.  This will help you
     find places where you've made a mistake in your math or
     made a bad assumption.

     4.  LEARN YOUR BACKGROUND.

     If you want to write a medieval fantasy game, read
     medieval literature and history.  Read books about magic.
     Read existing medieval fantasy games.  Similarly for
     any other type of game; if you're making a game set
     in the Vietnam war, read official histories of the war,
     unofficial histories, and especially analyses of strategy
     and tactics.

     All this background is useful in several ways:  for one
     thing, it will help you in creating realistic rules.  For
     another, it lessens the chance that you will make a major
     mistake in terminology or background.  And, of course,
     the material is often interesting in itself.  If you're
     not interested in learning about X, why are you writing
     a game about it anyways?

     5.  FORMAL EDUCATION.

     Take a class in introductory probability and statistics.
     Try reading some on the mathematical theory of games;
     you probably won't find it useful, but it does provide
     some perspective.  Polish your English (or whatever
     language you plan to publish your game in); games are
     much easier to learn when they're well-written, or at
     least don't have a lot of grammatical errors.

     If you want to do computer games and haven't already
     taken any programming classes, take a few.  You may not
     learn anything about how to program, but a good class
     will teach you some things about how to organize a
     program to make maintenance and bug-finding easier.

     While you're at it, build up a "reference library."
     This is a set of games and books on whatever subject
     you're making your game on.  This will help immensely
     when inspiration strikes at 3 AM and the library is
     closed.

     6.  TAKE TIME OFF.

     A game is like a child; when it's first born, it's
     parents think it's perfect.  Take some time away from
     your game to keep from getting burnt out and to get a
     fresh perspective on it.  Repeat this from time to
     time.

     7.  KEEP RECORDS.

     Make sure you have more than one copy of your game.  If
     you're typing the rules on a computer, keep one copy on
     the hard drive, one on a floppy, and a printout of a
     fairly recent version (say, print it out once a month,
     or once a week if you're working really fast).  You can
     never have too many copies, since if it's any good,
     friends will want copies to borrow/keep, and having all
     these copies will greatly reduce the chance of losing it
     all to a hard drive crash/lost notebook/whatever.

     In the same vein, keep copies of older versions as well.
     You may find in playtesting that your new idea isn't as
     good as the old one was, and what are you going to do
     now if you've trashed the old copy?  Keep at least one
     copy of the last version around, in addition to the
     copies of the current version.

     8.  DON'T FORGET THE INCIDENTALS.

     Great rules and writing are nice, but a good visual
     presentation will do wonders for your sales.  If you're
     doing it yourself, learn something about desktop
     publishing, and either find some ready-made illustrations
     (for example, in the Dover clip art stuff or US
     government publications) or find someone to draw a few
     illustrations for you.

     Find a printer and talk to him/her; discuss ways to do
     what you want as inexpensively as possible.  A lower
     price will help sales some, and lower expenses will
     help your profits.

     9.  REMEMBER, IT'S ONLY A GAME.

     Don't ignore real life to work on your game.  If someone
     doesn't like your game, don't take it personally.  Don't
     get worried about people stealing your ideas.  Remember
     rule #1 and have fun with what you're doing.

     10. THERE IS NO NUMBER 10.  :-)

     And, here's some extra advice from Tom Lehmann, president of
     Prism Games (thanks Tom!):

     A.  Incremental innovation often works best.  If everything in
     your game is familiar, it will feel stale.  If everything is
     very different, it may feel strange.  A single clever twist
     on a familar theme is good but may result in your game being
     viewed as a "variant"; TWO clever twists on familiar ideas
     makes a game feel fresh while still easily accessible.  So
     don't try to re-invent the wheel.  Instead, try to present
     existing ideas cleanly and simply while extending a few key
     concepts in new and interesting directions.

     B.  Revise and Polish your game ideas.  Testing serves not only
     to clean up bugs in the game system and rules presentation
     but also as the forum in which the game designer may
     discover the game that he or she *really* wanted to put
     forth, as opposed to the one they actually have put
     together.  If you leave testing to the end, this discovery
     may not do you any good.  If you test early and often with
     an eye towards trying to figure out just what the game
     really is about, you can often improve a game considerably.

     "Alpha" testing can be viewed as asking the questions: "Is
     there a game here?" and "Have I found it yet?"  "Beta"
     testing can be viewed as asking the questions: "Is this the
     best way to achieve this effect?", "Is this game mechanic
     essential -- or can it be simplified or eliminated?" and
     "Are all the major game systems working together to impart
     the game experience I want?" "Gamma" testing asks the
     question: "How can I improve game balance and presentation?"
     Too many designers stop after Alpha (producing an intriguing
     but shoddy game) or go from Alpha to Gamma, skipping Beta
     (producing games that are ok but not great).  Often it is
     neccessary to go beyond your immediate friends / local
     gaming group early on to get enough critical analysis for
     you to figure out what needs to be done to improve an
     already pretty good game.

     And some more from me:

     I've never had clear-cut "stages" of game testing when I
     made games; instead, I tend to do a bit of each at every
     stage.  I rework some systems, toss out some and replace
     them, and improve the balance and presentation of others,
     all more or less simultaneously.  Part of this comes from
     the type of the main game that I'm working on... when doing
     a universal RPG, you have to work on a piece at a time.

     The key, though, is to find whatever works best for you.
     Try it different ways until you find one that's comfortable,
     then stick with that.

---------------------------------------------------------------------

Section 2 -- RPG design

1.  What is net.rpg's current status?  [use net.rpg: in headers]

     Net.rpg is basically dead.  A net.rpg FAQ is kept by Magnus;
     it contains a summary of some of the discussion that took
     place about net.rpg.  (Magnus can be reached at
     [e-mail])

2.  What is net.rpg, for that matter?

     Net.rpg isn't really anything yet.  The idea is to try to hammer
     out a free role-playing game using the gathered game design
     talent here on the net.

     There was a large amount of discussion at first, but almost no
     one could agree with anyone else on what net.rpg should be like.
     Thus, after some time, the discussion died down.  The general
     consensus now seems to be that net.rpg is an impossible dream;
     you're never going to get that many game designers to agree on
     anything, unless you use some type of committee approach ... and
     we all know how good things designed by committee usually are!

     However, the net.rpg discussion did generate a fair amount of
     good ideas.

3.  What is FUDGE?  [use FUDGE: in headers]

     FUDGE is one of the products of the net.rpg discussion; not THE
     net.rpg, but a net.rpg.  FUDGE stands for Freeform Universal
     Donated Gaming Engine.  It's author is Steffan O'Sullivan, who
     semi-regularly posts a FUDGE FAQ.  ([e-mail])

     FUDGE is available from Wild Mule Games and via FTP
     from ftp.csua.berkeley.edu, in /pub/fudge.

     Wild Mule Games can be reached via snail mail at:

        P.O. Box 838
        Randolph, MA 02368-0838

     or via e-mail at

        [e-mail]

4.  I'm trying to design an RPG.  What advice do you have?

     1.  Don't think you're going to make money.  Chances are you
     won't.

     2.  Don't think you're going to sell it to any established RPG
     company; most of them don't want to dilute the market even
     further by releasing yet another game.

     3.  If you are trying to create a game for sale, don't make it
     too much like any established system... there are already
     far too may AD&D look-alikes out there.  Try to come up with
     something different.

     4.  Do make something *you* like... chances are that if you like
     it, someone else will too.  However, if you try to listen to
     the "experts" and follow their advice about how realistic
     the game should be, how long combat should take, etc. and
     end up with a game you don't like a lot, chances are no else
     will like it too much either.  Besides, if you're going to
     spend months or years writing something, shouldn't you have
     fun doing it?

     So, what does that leave?  Well, if you're doing it for your own
     use, or your friend's use, go right ahead.  If you're trying to
     break into the RPG business, you'd probably do best writing
     articles for RPG magazines and sending them in to them.  The
     industry is pretty close-knit, and word does get around about
     who does good work (and does it on time!).

---------------------------------------------------------------------

Section 3 -- Computer Games

1.  What is FRUA? [use FRUA: in headers]

     FRUA is short for Forgotten Realms Unlimited Adventures, a
     program from SSI for creating computer adventures like their
     AD&D series.  FRUA is not shareware or freeware; you should be
     able to order it from just about any software store.  There is
     a mailing list devoted to FRUA (address?).

2.  What's the best language to write a game in?

     That's a complicated question.  It depends on several things:
     your knowledge of computer languages, what kind of game you're
     writing, what computer you're writing it for, and what tools you
     have access to.

     My first advice would be to program it in a language you are
     familiar with, and the more the better.  There's nothing worse
     than spending most of your time looking in manuals instead of
     writing code.  Second, go with something widely used (e.g., C).
     The more widely used your language is, the better the chance is
     that you'll be able to find someone who can help you if you need
     it.

     With the preceding in mind, if you're writing a game for PC,
     Unix, or Macintosh platforms, I'd recommend C.  It's a powerful
     language, good implementations exist for all three of these
     platforms, and there are large numbers of C programmers out
     there who can help you.

---------------------------------------------------------------------

Section 4 -- Wargames and Boardgames

1.  I'd like to get a wargame published.  What should I do?

     Here's some advice from Kerry Anderson, quoted with his
     permission.

     ---- QUOTED TEXT BEGINS ----

     From: [e-mail] (Kerry Anderson)

     I've published three games through other companies.  These are
     MARINE:2002 (Yaquinto,1980), MOONBASE CLAVIUS (Taskforce, 1982),
     and CLASH OF EMPIRES (Wargamer issue 58?).  It's not easy and
     you're at the mercy of the company if they decide to publish.

     The first step is to write the best letter you can to these
     companies, giving the impression you know what you know what
     you're doing and that the game suits their line and that it will
     be a hot seller.  Expect to get no answer from some, "thanks but
     no thanks" from most, and "yes, send us a copy to evaluate" from
     a few.

     If you get the chance to send in the game, put every effort into
     producing a polished, final copy.  Give them the feeling that
     you are a professional and that you know what you are doing.
     Put great effort into the graphic quality of the game to catch
     their eye.  Write and edit the rules to death and print up the
     final product on a laser printer.  You must make the game as
     appealing as you can.  If the game is poorly put together, they
     might not want to bother trying to figure it out and reject it
     immediately.

     If the game is accepted, expect the worst in the final product.
     Let me describe my experiences:

     MARINE:2002 was my first game and admittedly was poorly put
     together.  They accepted it, but changed it inside and out.  I
     got bumped from "game designer" to "game concept".  Admittedly,
     it was a slick product when they finished it but it doesn't
     always turn out that way.

     MOONBASE:CLAVIUS was a polished game.  I got someone to edit and
     type the rules.  I sent it to Avalon Hill (who, by the way,
     rarely look at unknown designers) and it was rejected.  I sent
     it to Taskforce who immediately accepted it.  After about a
     year, they put it into one of their pocket games and decided to
     throw in a few changes like reversing the sequence of play to
     fight-move.  It destroyed the game but what could I do now?

     AUGUST 1914 was left virtually intact.  They even used my rules
     for the final text (with a couple of small changes).
     Regrettably, The map was abysmal and the counters hard to read.
     It drifted off into obscurity.

     As you can see, trying to sell games to other companies can be
     disheartening.  Expect a lot of rejection.  While I do have
     three games published, I've had several of my games rejected,
     such as VIMY RIDGE (for being too realistic) and THE BATTLE OF
     ARMAGEDDON (for not being apocalyptic enough) by XTR - both game
     prototypes UNPLAYED (am I bitter?).  You may be better off
     trying to do it yourself.  This is something I'm seriously
     thinking about now.

     Kerry Anderson

     ---- QUOTED TEXT ENDS ----


2.  FTP-able boardgames.

     There are a few boardgames available by FTP.  Among them are:

     BARNARD'S STAR, by Kerry Anderson

       Available from sunbane.engrg.uwo.ca as /pub/postscript/bseps.zip.
       This is a pkzipped set of EPS files which contain all the
       components of the game.  To use it, you'll need something which
       can unzip files and a postscript printer.

       BARNARD'S STAR is a science fiction game on an attack on an
       outpost on a moon in the Barnard's Star system.  Units are company
       sized and the scale is 100 km per hex and 10 hours per turn.  The
       game contains lots of neat SF chrome including bombardment from
       space, planetary defenses, jump troops, teleporation, etc.

     BARONS OF FYN, by Joshua Howard

       Available from archive.umich.edu, in directory mac/game/card.
       The file is a mac compressed postscript archive.

       Barons of Fyn is a card game, produced by Bone Games, which
       also has other ftp-able games.


--
Travis S. Casey                      <[e-mail]>
FAQ maintainer for rec.games.design
<A funny quote should go here>